Existing analog and mixed-signal (AMS) simulators, such as the VHDL-AMS and Verilog-AMS simulators, have the capability to simulate pure VHDL-AMS and pure Verilog-AMS designs respectively. A detailed description of working with pure VHDL-AMS components is found in “IEEE Standard VHDL Analog and Mixed-Signal Extensions,” published by IEEE-SA Standards Board on Dec. 23, 1999. And a detailed description of working with pure Verilog-AMS components is found in “Verilog-AMS Language Reference Manual—Analog & Mixed-Signal Extensions to Verilog HDL,” published by Accellera International Inc. on Jan. 20, 2003. However, circuit designers are interested in using design components from both languages, and they do not want to be constrained to either the VHDL-AMS or the Verilog-AMS languages. The basic issue in supporting a mixed-language mixed-signal simulator lies in the lack of compatibility between the VHDL-AMS and Verilog-AMS languages.
In a mixed-language mixed-signal (MLMS) design where one or more VHDL-AMS and Verilog-AMS components are connected to each other, a number of possible connections may be encountered that require special processing. Table 1 illustrates four fundamental cases for supporting a mixed-language mixed-signal design environment when a Verilog-AMS component is connected to a VHDL-AMS component.
TABLE 1Verilog-AMS ComponentVHDL-AMS ComponentCase 1Verilog-AMS analog objectVHDL-AMS analog objectCase 2Verilog-AMS digital objectVHDL-AMS analog objectCase 3Verilog-AMS analog objectVHDL-AMS digital objectCase 4Verilog-AMS unresolved netVHDL-AMS digital or analogcomponent
Of the four fundamental cases listed in Table 1, Case 2 and Case 3 are not supported by the prior art simulators. Although the prior art simulators provide a limited support of Case 1, it is done without performing a compatibility check to ensure the connection between the Verilog-AMS analog object and the VHDL-AMS analog object is valid.
Similarly, although the prior art simulators provide a limited support of Case 4, there are a number of drawbacks with the prior art approaches. In particular, to support a connection between a Verilog-AMS unresolved net and a VHDL-AMS digital net, the Verilog-AMS unresolved net is forced to become a digital net. In addition, to support a connection between a Verilog-AMS unresolved net and a VHDL-AMS analog net, the Verilog-AMS unresolved net is forced to be an analog net. This approach is merely a temporary solution for ensuring that the nets that are connected across the language boundary belong to the same domain (digital-to-digital or analog-to-analog). However, the prior art approach does not follow the discipline resolution semantics established by the Verilog-AMS Language Reference Manual (LRM). Besides, this temporary solution does not work in the situation when a Verilog-AMS unresolved net is connected to a VHDL-AMS analog net and a VHDL-AMS digital net, because the unresolved net can be forced neither to an analog net nor to a digital net in that situation.
Moreover, the prior art approach in Case 4 is inflexible in supporting the connection of a Verilog-AMS unresolved net with VHDL-AMS analog port. This is because it uses only the nature of VHDL-AMS port in the discipline resolution of the unresolved Verilog-AMS net. In other words, the prior art approach does not take into account the hierarchical and library information of the nature of the VHDL-AMS analog port. Thus, it produces inaccurate mapping result between the Verilog-AMS unresolved net and the VHDL-AMS analog port.
Furthermore, a Verilog-AMS discipline name is case sensitive, whereas a VHDL-AMS nature name is case insensitive. In other words, in the VHDL-AMS language, names like “xyz” and “XYZ” are interpreted to be the same name. But in the Verilog-AMS language, these names are interpreted to be different names. The prior art simulators do not address the case of incompatibilities between the two languages when using the VHDL-AMS nature name in the Verilog-AMS discipline resolution process.
Finally, there are incompatibilities between the definition of Verilog-AMS disciplines and the definition of VHDL-AMS natures. The Verilog-AMS disciplines are defined as a global parameter (global scope), which affects all levels of hierarchy of the design. On the other hand, some VHDL-AMS natures may be defined as a local parameter (local scope), which affects only the specific level of hierarchy of the VHDL-AMS design where the VHDL-AMS nature is defined. Therefore, in the VHDL-AMS language, a nature name alone is not enough to uniquely identify a nature. For example, in a VHDL-AMS design, there may be more than one nature of the name “electrical” defined in the different hierarchies (scopes) of the VHDL-AMS design and these natures may be completely different from each other.
Therefore, there is a need to address the issues of the prior art simulators in enabling circuit designers to use design components from both Verilog-AMS and VHDL-AMS languages in a MLMS environment. In particular, there is a need to provide solutions to each of the four cases of Table 1 to enable connections between Verilog-AMS and VHDL-AMS components. In addition, there is a need to uniquely identify a VHDL-AMS nature by its selected name not only includes that nature's name but also includes the names of its relevant hierarchy (scope) and library information.